The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The TMN (Telecommunications Managed Network) hierarchy defines five layers of management systems that may be used to manage telecommunications networks. At each layer, there are associated management systems. Systems at the upper four layers include Business Management Systems (BMS), Service Management System (SMS), Network Management Systems (NMS), and Element Management Systems (EMS). At the network element layer, there are interfaces to the higher-level systems, usually based on established protocols (e.g., TL1, SNMP, etc.).
According to TMN standards, Network Management Systems deal with network capabilities including the managed view of the network focusing on end-to-end connectivity (and presentation of a network view to SML). Element Management Systems deal with network element data such as logs and control of managed portions of network elements, and mediation between the Network Management Layer (NML) and Network Element Layer (NEL). Network Element layer systems deal with interfaces between managing system and equipment.
Accordingly, many vendors have built Craft Management Systems (or craft tools) that allow a craft technician to perform setup and repair activities for the network elements. Most craft tools provide ASCII based entry windows where the craft technician is required to input commands with a specific syntax in order to produce an expected response from the network element. Over the past decade, more craft tools have started to use a graphical user interface (“GUI”) approach, although most simply convert a user's action into the associated ASCII commands. The move from ASCII command interfaces to user-friendly GUIs in craft tools has increased user productivity and reduced errors.
Most craft tools that are based on ASCII command entry windows interact with a single network element at a time. This is the paradigm that the TMN standards expect and most vendors have implemented. Although this has proved to be a successful paradigm, the responsibility for interacting correctly with each node, in the correct order, is placed on the craft technician. Some operations require interaction with multiple network elements. Although these can be done through interacting with each node separately, the chance for user error is significant. There has been no way to interact with the network as a whole.
An example of a GUI-based craft tool is Cisco Transport Controller (CTC), from Cisco Systems, Inc., San Jose, Calif. The user interface of CTC is implemented using Java and Common Object Request Broker Architecture (CORBA) is used to interface between the network element and the craft tool. CORBA uses IP to communicate with network elements over a SONET/SDH DCC. Topology discovery is accomplished using Open Shortest Path First (OSPF).
To further assist users in performing complex network management functions, GUI-based craft tools have implemented software wizards. A wizard may be defined as an interactive utility that guides the user through a potentially complex task. Wizards are often implemented as a sequence of dialog boxes that the user can move forwards and backwards, filling in the required details. In theory, the expertise of a human wizard is encapsulated in the software wizard, allowing the average user to perform expertly. Despite the many advantages offered by GUI-based craft tools, certain tasks have remained difficult or error-prone. Establishing a bi-directional line switched ring (BLSR) in a telecommunication network is an example of such deficiencies. In the typical approach, a user who wants to set up a BLSR needs to interact with each network element separately. Proper setup requires the user to enter compatible parameter values in data entry forms for the individual nodes participating in that ring. For example, proper ring setup requires each node to have the correct port value entered for an East port and a West port of the node. If the user enters inconsistent values, the ring will not work. As another example, the typical approach requires a user to enter numeric values, such as the ring identifier and reversion time, at each node. A BLSR ring could have up to 32 nodes, which increases dramatically the chance for introducing errors. An incorrect entry for any of the nodes would cause the ring to be malformed and inoperative. The user would have no way to determine, before provisioning the data to a network element, that the user had entered incorrect data values.
Thus, in the past, there has been no way to control multiple non-connected sub-networks to define higher-level concepts, such as a ring in its entirety, and provision multiple network elements concurrently and automatically.
Based on the foregoing, there is a clear need in this field for a way to enter information that applies to all nodes at once.
There is a clear need for a way to control multiple non-connected sub-networks for various management purposes. For example, there is a need to provide some way to propagate the information to all nodes concurrently and automatically, so that the craft technician can focus on defining network-level concepts without having to interact repeatedly with multiple network elements.
There is also a need for a way to check user data entry to identify errors before the data is provisioned to a network element.
There is a particular need for an improved way to define and automatically provision a bi-directional line switched ring (BLSR) in a service provider network.